Ray, Excellent points! However, Kmotioncnc currently can only start from the beginning of a program - at least, I haven't figured out anything different. Michael
Sent from my Verizon Wireless Droid
Group: DynoMotion |
Message: 5887 |
From: Tom Kerekes |
Date: 10/25/2012 |
Subject: Re: run from here |
Hi Michael,
If you Right-Mouse-Click in the GCode Window there is a "Set Next Statement" option. But it is totally up to you to make sure the next and following statement(s) makes sense. For example if the last thing executed was a G2 arc and you move the instruction pointer to the middle of some xy statements that follow a G1 then the result wouldn't make any sense, generate an error, or a crash.
There are about an infinite number of ways that things would go wrong, wrong tool loaded, wrong fixture offset, wrong radius comp, wrong units, unspecified axis, wrong plane, jumping into the middle of a subroutine, spindle off, variables with wrong values, etc etc etc...
In some cases we might be able to search backwards and figure out if things are reasonable or not, but that doesn't often work. We are open for suggestions in this area but we don't want to do things that will be too complex and unpredictable.
Regards
TK
Group: DynoMotion |
Message: 5888 |
From: himykabibble |
Date: 10/25/2012 |
Subject: Re: run from here |
Tom,
In Mach3, RunFromHere does a simulation of all G-code up to the selected point, to ensure all modals are properly set. It will also do a "preparatory move" to the correct current position so the program, can resume, or begin, execution from the selected point. However, as I indicated, it is far from fool-proof.
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Michael,
> Â
> If you Right-Mouse-Click in the GCode Window there is a "Set Next Statement" option. But it is totally up to you to make sure the next and following statement(s) makes sense. For example if the last thing executed was a G2 arc and you move the instruction pointer to the middle of some xy statements that follow a G1 then the result wouldn't make any sense, generate an error, or a crash.Â
> Â
> There are about an infinite number of ways that things would go wrong, wrong tool loaded, wrong fixture offset, wrong radius comp, wrong units, unspecified axis, wrong plane, jumping into the middle of a subroutine, spindle off, variables with wrong values, etc etc etc...
> Â
> In some cases we might be able to search backwards and figure out if things are reasonable or not, but that doesn't often work. We are open for suggestions in this area but we don't want to do things that will be too complex and unpredictable.
> Â
> Regards
> TK
> Â Â Â Â
>
>
> From: "mrosenfield@..." <mrosenfield@...>
> To: DynoMotion@yahoogroups.com
> Sent: Thursday, October 25, 2012 8:18 AM
> Subject: Re: [DynoMotion] Re: run from here
>
> Â
> Ray,Excellent points!However, Kmotioncnc currently can only start from the beginning of a program - at least, I haven't figured out anything different.MichaelSent from my Verizon Wireless Droid
Group: DynoMotion |
Message: 5889 |
From: mrosenfield@hotmail.com |
Date: 10/25/2012 |
Subject: Re: run from here |
Aha! Didn't think to right ckick! Yes, I know that this is a very tricky thing to do, and I have no good ideas about how to make it less so. I would use this only for debugging; after trying some things, I resolved to repost the whole program to make changes. Thanks, Tom
Sent from my Verizon Wireless Droid -----Original message----- From: Tom Kerekes <tk@...> To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com> Sent: Thu, Oct 25, 2012 15:46:38 GMT+00:00 Subject: Re: [DynoMotion] Re: run from here
Hi Michael,
If you Right-Mouse-Click in the GCode Window there is a "Set Next Statement" option. But it is totally up to you to make sure the next and following statement(s) makes sense. For example if the last thing executed was a G2 arc and you move the instruction pointer to the middle of some xy statements that follow a G1 then the result wouldn't make any sense, generate an error, or a crash.
There are about an infinite number of ways that things would go wrong, wrong tool loaded, wrong fixture offset, wrong radius comp, wrong units, unspecified axis, wrong plane, jumping into the middle of a subroutine, spindle off, variables with wrong values, etc etc etc...
In some cases we might be able to search backwards and figure out if things are reasonable or not, but that doesn't often work. We are open for suggestions in this area but we don't want to do things that will be too complex and unpredictable.
Regards
TK
| | | | | | | |